At first, the GMPLS/MPLS network and a path establishing signaling protocol used in the GMPLS/MPLS will briefly be explained. Then, thereafter, a conventional route tracing method will be described.
(GMPLS/MPLS)
The GMPLS/MPLS is a technology of forwarding data according to label information. The label information is defined such as a fixed length label attached to the head of a packet, a timeslot of time division transmission and a light wavelength in optical multiplexing transmission. Particularly, a network for forwarding the packet by use of the fixed length label attached to the head of the packet is called an MPLS network. Note that the GMPLS network involves using any one piece or some pieces of label information including the fixed length label employed in the MPLS network.
For example, in the packet transfer using the fixed length label, a relay node (LSR: Label Switched Router) retains a label table having a relationship between a tuple of input label/input IF (Interface) and a tuple of output label/output IF (Interface). Then, when relaying the packet, the output IF is determined based not on an address but on the label attached to the received packet, the label attached to the packet is rewritten into the output label, and the packet is thus relayed. This process being repeated, the packet is transmitted to the destination. Note that a relay node at an ingress (ingress node) of the GMPLS/MPLS network attaches the label for the first time. This is the fast packet relay technology.
FIG. 21 is an explanatory diagram of a packet relay method. Herein, the packet is forwarded to an LSR 4 from an LSR 1. To begin with, the LSR 1 attaches a label a to the packet to be forwarded. Then, the LSR 2, when receiving the packet attached with the label a via an interface IF#1, acquires the output IF and the output label by searching the label table. Subsequently, after rewriting the label of the packet into the output label, the packet is output to the output IF. This process being repeated, the packet is forwarded to an egress LSR 4 (egress node). Thus, the packet is forwarded according to the fixed length label, thereby enabling the packet relay to be speeded up.
Moreover, in the relay node, bandwidth guarantee for each packet flow can be implemented by associating each label with bandwidth control in the relay node.
In the time division transmission, each node retains a label table having a relationship between a tuple of input timeslot/input IF (Interface) and a tuple of output timeslot/output IF. Then, each node determines, based on a reception IF and a reception timeslot, the output IF and the output timeslot, and outputs the data to the output timeslot of the output IF. This process being repeated, the data is transmitted to the destination.
In the optical multiplexing transmission, each node retains a label table having a relationship between a tuple of input light wavelength/input IF (Interface) and a tuple of output light wavelength/output IF. Then, each node determines, based on the reception IF and the reception light wavelength, the output IF and the output light wavelength, then converts the reception light wavelength into the output light wavelength, and outputs the data to the output IF. This process being repeated, the data is transmitted to the destination.
The GMPLS is a technology of performing the transfer with the same mechanism in a way that deals with each of the fixed length label, the timeslot and the light wavelength as the label.
(Path Establishing Signaling Protocol (RSVP-TE: Resource reSerVation Protocol-Traffic Extension))
FIG. 22 is a diagram illustrating an operation of the path establishing signaling protocol.
In the GMPLS/MPLS, each node is required to organize the label table. Therefore, the path establishing signaling protocol (CR-LDP (Constraint-based Routing Label Distribution Protocol)/RSVP-TE) as in FIG. 22 is employed.
Hereinafter, the path establishing operation with the aid of organizing the label table will be described by exemplifying the RSVP-TE. The ingress node making the path establishing request transmits a path establishing request message (Path message) to the egress node of the path in a hop-by-hop (node-to-node) mode. In the example of FIG. 22, the information about the relay hop-to-hop nodes is inserted into the Path message in order to explicitly designate a route. The egress node receiving the Path message sends a path establishing response message (Resv message) for allocating the label back to the ingress node along the route on which the Path message has been transmitted. At this time, the label stored in the Resv message is registered in the label table, thereby organizing the label table for forwarding the data. A path ID is stored in both of the Path message and the Resv message and is registered together in the label table.
(Conventional Route Trace Information Acquiring Method RRO)
FIG. 23 I a diagram illustrating an operation of a route tracing function which uses RRO (Record Route Object).
The following discussion will deal with a conventional technique for actualizing the route tracing function by exemplifying the RSVP-TE. The IETF Standards (Non-Patent document 1, Non-Patent document 4) define a technique using the RRO as a technique of actualizing the route trace in the RSVP.
The operation thereof will hereinafter be described (FIG. 23). The ingress node making the route trace request inserts an object RRO for making the route trace request into the path establishing request (Path)/response (Resv) message, and, after adding a self-node identifier as a RRO sub-object, transmits the path establishing message (Path message) in the hop-by-hop mode. An intermediate node receiving the Path message determines, the RRO sub-object being inserted therein, that the route tracing function is set effective, and, after adding the self-node identifier as the RRO sub-object to the list, forwards the Path message to a next hop (next node). The respective intermediate nodes execute regular procedures, whereby the RRO containing the list of the nodes via which the Path message is sent is carried through the Path message down to the egress node eventually. The egress node receiving the Path message inserts the RRO object and the sub-object containing the self-node identifier into the response (Resv) message, and sends this message back to the ingress node along the route on which the Path message has been sent. The intermediate node receiving the Resv message containing the RRO sub-object, after adding the self-node identifier as the RRO sub-object to the list, forwards the Resv message to the next hop (next node). The RRO containing the list of the nodes via which the Resv message has been sent is carried up to the ingress node through the Resv message. Each node can acquire the list of the node group located on an uplink of the self-node from the Path message and the list of the node group locates on a downlink of the self-node from the Resv message and can acquire the information about the nodes via which the established path extends from these two items of information by performing the procedures described above.
FIG. 24 is a flowchart illustrating the standard specification processing flow described above. Each relay node, upon receiving the path establishing request (or the response), checks whether this message contains the route record request (RRO) or not. The relay node, if the route record request is contained, adds the self-node identifier to the route information list and transmits the path establishing request (or the response) to the next node. If the route record request is not contained, the relay node transmits the path establishing request (or the response) as it is to the next node.    [Patent document 1] Japanese Patent Laid-Open Publication No. 2000-244563.    [Non-Patent document 1] D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan, G. Swallow, “RSVP-TE: Extensions to RSVP for LSP Tunnels.” Network Working Group Request for Comments (RFC) 3209, December 2001.    [Non-Patent document 2] L. Berger, Ed., “Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description.” Network Working Group Request for Comments (RFC) 3471, January 2003.    [Non-Patent document 3] L. Berger, Ed., “Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions.” Network Working Group Request for Comments (RFC) 3473, January 2003.    [Non-Patent document 4] K. Kompella, Y. Rekhter, “Signaling Unnumbered Links in Resource ReSerVation Protocol-Traffic Engineering (RSVP-TE).” Network Working Group Request for Comments (RFC) 3477, January 2003.    [Non-Patent document 5] J. Moy, “OSPF Version 2.” Network Working Group Request for Comments (RFC) 2328, April 1998.    [Non-Patent document 6] D. Katz, K. Kompella, D. Yeung, “Traffic Engineering (TE) Extensions to OSPF Version 2.” Network Working Group Request for Comments (RFC) 3630, September 2003.    [Non-Patent document 7] K. Kompella, Ed., Y. Rekhter, Ed., “Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS).” Network Working Group Request for Comments (RFC) 4202, October 2005.    [Non-Patent document 8] K. Kompella, Ed., Y. Rekhter, Ed., “OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS).” Network Working Group Request for Comments (RFC) 4203, October 2005.